クロスアカウントな AWS Transit Gateway を、絵で見て（完全に）理解する。

Transit Gatewayに関連するコンポーネントとして何があるか、そしてクロスアカウントの場合にそれらのコンポーネントはどちらの持ち物かを絵を描いて整理しました。

#図解

#クロスアカウント

#AWS Transit Gateway

#Amazon VPC

#ネットワーク

千葉幸宏（チバユキ）

2020.02.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

みなさん、Transit Gateway理解してますか？

私は、一足先に完全に理解することに成功しました。

トランジットゲートウェイ完全に理解したな

— Batchi (@batchicchi) February 16, 2020

「そもそもTransit Gatewayってどんなコンポーネントがあるの？」や、「アカウントまたぐときにどちら側で作成・管理するの？」というのが初見では分からなかったので、絵を描いて理解しました。ぜひそのアウトプットを見て、皆さんにも完全に理解していただければと思います。具体的な操作手順については、先人のブログ（後述）があるので、本記事では触れません。あくまでイメージを掴むためにご活用ください。

前提

AWSアカウントが2つある
Transit Gatewayをアカウント間で共有する
アカウントを跨いだVPC間で通信を行う

実際にはこの規模でTransit Gatewayを使うことはそうそうないでしょうが、接続先の環境が増えても、基本的な考え方は同じです。全体像のイメージとしては以下のようになります。

本稿では左側のAWSアカウントを「共有元」、右側のAWSアカウントを「共有先」と呼びます。

先に結論

基本的な考え方

Transit Gateway一般の考え方です。

Transit Gatewayのコンポーネントには以下がある
- Transit Gateway
- Transit Gateway ルートテーブル
- Transit Gateway アタッチメント
Transit Gatewayのコンポーネント間で行う動作として以下がある
- アソシエート（ルートテーブルとアタッチメントの関連付け）
- プロパゲート（アタッチメントからルートテーブルへのルートの伝播）
デフォルトTransit GatewayルートテーブルはTransit Gateway作成時のパラメータによって作成されるか否かが決定する
デフォルトTransit Gatewayルートテーブルに、以下のいずれかもしくは両方の機能を有効にできる
- Transit Gatewayに追加されたアタッチメントに対して自動的にアソシエートする
- Transit Gatewayに追加されたアタッチメントから自動的にプロパゲートされる

上記の前提の構成において

今回の前提における特記事項です。

Resource Access Managerでアカウント間で共有できるのはTransit Gatewayのみである
- アタッチメントやルートテーブルは共有できない
Transit Gateway アタッチメントはそれぞれのAWSアカウントで作成する
共有先で作成したアタッチメントは共有元で承認する必要がある
- 自動的に承認する設定も可能である
Transit Gateway ルートテーブルは共有元でのみ作成する
アカウントをまたいでコンポーネントを参照する場合、相手側でつけたタグは見えない

以下、一連の流れを確認していきます。

Transit Gatewayの作成・共有

まずはTransit Gatewayを作成します。作成時には、以下のパラメータを設定可能です。

パラメータ	概要
Name tag	Nameタグ
Description	説明
Amazon side ASN	Amazon側のBGPセッションのAutonomous System Number
DNS support	Transit Gateway経由のVPC内のインスタンスからパブリックDNS→プライベートIPの名前解決を有効にするかどうか
VPN ECMP support	VPN間でEqual Cost Multipath ルーティングが必要な場合に有効化する
Default route table association★	デフォルトTransit Gatewayルートテーブルを作成し、新規のアタッチメントに自動的にアソシエーションさせる
Default route table propagation★	デフォルトTransit Gatewayルートテーブルを作成し、新規のアタッチメントから自動的にプロパゲーションさせる
Auto accept shared attachments★	クロスアカウントのアタッチメントを自動的に承認する

★マークがついているものは後続の手順で改めて取り上げます。

Create a Transit Gateway

作成時の画面イメージ。

Transit Gatewayの共有

この後に出てくるアタッチメント、ルートテーブルを先に作成してもよいのですが、最終的に共有するのはTransit Gatewayのみなので、この段階で共有します。

Resource Access Managerを用いて共有を行います。共有をする際には、以下の流れとなります。

共有元アカウントで「共有」を作成
共有先アカウントで「共有」を承認

共有されたのちは、共有先アカウントでTransit Gatewayを参照可能になります。なお、共有元アカウントで付与したタグを見ることはできません。必要に応じて、共有先アカウントで改めてタグの付与を行う必要があります。

Transit Gateway アタッチメント

アタッチメントを作成する際には、大まかには以下を設定します。

どのTransit Gatewayに紐づくものととして作成するか（図中の紫破線はそれを表しています。）
どのVPCに関連付けるか
- さらには、どのサブネットに関連付けるか

アタッチメントの作成時の画面イメージ。

選択したサブネットには、Transit GatewayによりENI（ネットワークインタフェース）が作成されます。なお、ここで選択できるサブネットは（同一VPC内において）AZごとに1つまでです。

このENIを他のAWSリソースと同居させず、独立したサブネットに作成することが推奨されています。同居させると同一のサブネットルートテーブルを参照することになるので、その影響を回避することが目的です。通信を監査用インスタンスにインターセプトさせたいなど、特殊なルーティングをしたい場合にバッティングするケースが想定されています。

A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。例えば　インライン監査用の VPC の TGW の ENI がある Subnet 上に EC2 インスタンスを設置してしまうと、その EC2 インスタンスは必ずインライン監査のミドルボックス ENI に吸い込まれてしまい、EC2 インスタンスの意図するルーティングテーブルを作れなくなってしまいます。こういったことを防ぐために、TGW 専用のサブネットを作ることをお薦めしています。

https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-transit-gateway-2019/より

クロスアカウントの場合

共有先のAWSアカウントのアタッチメントについては、以下の考慮事項があります。

共有元のAWSアカウント上で共有先のアタッチメントを作成することはできない
- アタッチメント作成時に必要な共有先アカウントのVPCが参照できないため
Transit Gatewayが共有されていない状態では共有先でアタッチメントを作成することはできない
- アタッチメントはTransit Gatewayに紐づくコンポーネントであり、スタンドアロンで作成できないため
アタッチメントの作成時に共有元AWSアカウントで承認を待つプロセスがある

共有元のアカウントで承認を実行しているイメージ画面。

承認するまでは、共有先のアタッチメントはpending acceptanceというステータスになっています。Transit GatewayのパラメータAuto accept shared attachmentsが有効になっていれば、この承認プロセスが自動で行われます。

ここでは共有先のマネジメントコンソールでアタッチメントにタグを付与済みなのですが、共有元ではそれが確認できないことが分かります。

Transit Gatewayルートテーブル

Transit Gatewayルートテーブルを作成します。今回は、以下の組み合わせで作成する前提としていますが、設定によって変更可能な部分です。

共有元のアタッチメントにはデフォルトTransit Gatewayルートテーブルを使う
共有先のアタッチメントには通常のTransit Gatewayルートテーブルを使う

Transit Gatewayの作成時に以下のいずれか（もしくは両方）を有効にしていた場合、そのパラメータが有効化されたデフォルトTransit Gatewayルートテーブルが自動的に作成されます。

Default route table association
Default route table propagation

今回の例では、共有先用のTransit Gatewayルートテーブルはデフォルトのものではないものを使用するため、手作業で作っています。アタッチメントの場合と異なり、共有元のアカウントで作成する必要があることに注意してください。作成するだけなら、「どのTransit Gatewayに関連づけるか」を選ぶだけで済みます。

Transit Gatewayルートテーブル作成時の画面イメージ。

アソシエーション

作成したTransit Gatewayルートテーブルはいずれかのアタッチメントに関連づけることで機能します。この関連付けをアソシエーションと呼びます。

今回の例ではTransit Gatewayルートテーブルとアタッチメントが1対1になっていますが、一般的には以下のような関係性になっています。

Transit Gatewayルートテーブルの視点では、複数のアタッチメントとアソシエーション可能
アタッチメントの視点では、いずれか一つのTransit Gatewayルートテーブルとのみアソシエーション可能

Default route table associationが有効なTransit Gatewayルートテーブルの場合、新規に作成されたアタッチメントには自動的にそのルートテーブルがアソシエーションされます。

そうでない場合は、手動でアソシエーションする必要があります。

アソシエーション作成時の画面イメージ。

プロパゲーション

Transit Gatewayルートテーブルからアタッチメントに対してプロパゲーションを作成することで、以下のルートが追加されます。

CIDR	Attachment
アタッチメントが関連づくVPCのCIDR	指定したアタッチメント

（今までの図ではしれっとTransit Gatewayルートテーブルの項目を「宛先」「ターゲット」と書いていたのですが、正しくは「CIDR」「Attachment」です。前者の表現のほうが個人的にわかりよいので、このまま行きます。）

アソシエーションとプロパゲーションは相互に関連するものではないので、「アソシエーションはしないけどプロパゲーションはする」ということも可能です。

Default route table propagationが有効なTransit Gatewayルートテーブルの場合、新規に作成されたアタッチメントに対して自動的にプロパゲーションを行います。そうでない場合、手動でプロパゲーションする必要があります。

プロパゲーション作成時の画面イメージ。

ここまで見てきたプロパゲーションによるルートの追加は「動的なルート追加」ですが、Transit Gatewayルートテーブルは静的なルート追加にも対応しています。ネクストホップでない宛先のCIDRを書いたり、デフォルトルートを書いたり、ブラックホールなルートを書いたり、自由に書けます。

サブネットルートテーブル

各々のサブネットで、要件に応じて設定します。特記事項としては以下のあたりです。

Transit Gatewayからプロパゲートするような仕組みはない
ターゲットはアタッチメントやそこで作成されたENIではなくTransit Gatewayそのもの

前者に関しては、「よくある質問」に記述がありました。

AWS Transit Gateway ルートテーブルのルートは、Amazon VPC のルートテーブルには伝播されません。Amazon VPC の所有者は、トラフィックを AWS Transit Gateway に送信するには、静的ルートを作成する必要があります。 https://aws.amazon.com/jp/transit-gateway/faqs/

後者に関しては、VPCのルートテーブルのドキュメントで、ターゲットにtgw-idを指定していることが読み取れます。このドキュメントに限りませんが、Transit Gatewayルートテーブルに関する記述か、VPC側のサブネットルートテーブルの記述かは、混同しないように気をつけましょう。

トランジットゲートウェイのルーティング

ここまでで、コンポーネント間の関係がイメージできていると幸いです。